-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(sl): fix error code #1366
fix(sl): fix error code #1366
Conversation
This stack of pull requests is managed by Graphite. Learn more about stacking. Join @kishore03109 and the rest of your teammates on Graphite |
abf0d0e
to
e64a239
Compare
export const ALLOWED_DNS_ERROR_CODES = ["ENOTFOUND", "ENODATA"] | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm ENOTFOUND
seems to be a catch all actually, should we be including this in the list of acceptable error codes?
From the node dns docs:
Keep in mind that err.code will be set to 'ENOTFOUND' not only when the host name does not exist but also when the lookup fails in other ways such as no available file descriptors.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do you know of any other way to capture no host name ah?
i agree that this is not the best way since we have a blind spot here, but their api does not seem to have an check for just the existence of a host name.
note that do have an error code for say timeout (ERR_SOCKET_CONNECTION_TIMEOUT
), so was hopeful that this would enough to catch transient network errors
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this happen on every site launch? Or is this an infrequent error caused by the agency not putting up their records in time? If it's infrequent there might be value in having to manually check, rather than possibly giving the agency a false positive
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This check happens once every site launch. But the error 'ENOTFOUND' is specifically thrown for every new domain that is being launched. We have had multiple incidents happen due to human error during SL (think one happened just this week with the pr to indirection layer iirc), so I am very inclined not to have manual checks. This PR's test plan has a sense check by running dns.promises on your docker for both resolve6 AND CAA for sites that have and dont have the above values. My stance is errors slip through will be rare, and as such the false positive is low enough to not affect operations.
Problem
There was a bug in the implementation of #1355. This worked for sites that were already launched. Newer sites which do no resolve to any host name throws a
ENOTFOUND
, which should be an ok error.Solution
To fix this issue, we explicitly check for this error code as well to ensure that this does not error out.
Breaking Changes
Tests
tldr; below we are testing for
Locally enter these values into
support/routes/v2/formsg/index.ts
assert that the console log outputs